From af976cb9bda10933544f4e80924f148472167df6 Mon Sep 17 00:00:00 2001
From: "kaf24@firebug.cl.cam.ac.uk" <kaf24@firebug.cl.cam.ac.uk>
Date: Fri, 5 Aug 2005 09:01:30 +0000
Subject: [PATCH] Instead of queuing messages when the control channels are
 full, xcs just does nothing (see ctrl_interface.c:ctrl_chan_write_request()).

The following patch throttles the rate in which consoled writes data to
xcs.  With the current values, you get a responsive console but avoid
data corruption in most scenarios.

I'm able to get pretty far in my regression test with this patch.  With
higher throttle values I'm able to get even further (but the console
becomes painfully slow).

I implemented proper control channel queuing in xenctld in VM-Tools and
it's pretty nasty stuff.  This should prevent corruption for most users
until we can get rid of xcs.

Regards,

Anthony Liguori

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com
---
 tools/consoled/io.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/tools/consoled/io.c b/tools/consoled/io.c
index 52b047fe80..364245f019 100644
--- a/tools/consoled/io.c
+++ b/tools/consoled/io.c
@@ -288,6 +288,7 @@ void handle_io(void)
 	fd_set readfds, writefds;
 	int ret;
 	int max_fd = -1;
+	int num_of_writes = 0;
 
 	do {
 		struct domain *d;
@@ -312,6 +313,17 @@ void handle_io(void)
 		}
 
 		ret = select(max_fd + 1, &readfds, &writefds, 0, &tv);
+		if (tv.tv_sec == 1 && (++num_of_writes % 100) == 0) {
+			/* FIXME */
+			/* This is a nasty hack.  xcs does not handle the
+			   control channels filling up well at all.  We'll
+			   throttle ourselves here since we do proper
+			   queueing to give the domains a shot at pulling out
+			   the data.  Fixing xcs is not worth it as it's
+			   going away */
+			tv.tv_usec = 1000;
+			select(0, 0, 0, 0, &tv);
+		}
 		enum_domains();
 
 		if (FD_ISSET(xcs_data_fd, &readfds)) {
-- 
2.30.2